又到了每半年一次的跨部門協調會議。按慣例，所有 Team Leader 都聚集在一起，討論未來的半年要做哪些事情。經過大半天的溝通、協調、來回討論，我們列出了每個部門下半年要做的事，也排了順序。
「不對呀！我們這一塊怎麼這麼大塊？」負責 API 部門的主管 Mike 出聲了：「不是說好了一個部門合理工作量是半年六個 Epic 嗎？現在 15 個 Epic 是要我們怎麼處理？」
大家紛紛湊過來幫忙看看發生什麼事。
「這個澳大利亞行銷案，不是要等明年法令看會不會鬆綁再決定嗎？」Mike 問。
「不行！這個我們要先做一個 Demo，否則我們年底預計的發廣告量會不夠。」行銷的 Amy 說話了。
「那那個新款產品核心演算法，不是說好了等 prototype 出來再看決定怎麼做嗎？」Mike 又問。
「對呀！但我們的人說你們不先出一版演算法，我們前端會做不出很像的效果。所以你們要先做，我們才能開始動工。」前端首席 Leo 發聲了。
「那就不叫 prototype 了不是嗎？」Mike 不放棄。
「但你們不先做我們就做不下去啦！」Leo 也很堅持。
「那… 那後台的會計總帳功能，不是現在已經有第三方 Solution 可用了嗎？為什麼要急著現在自己做一個幾乎一樣的東西？」Mike 繼續努力著。
「第三方系統做出來的報表太醜了啦！人家前端已經安排好時程了。」會計部的 Linda 也說話了，「我就叫前端先 GO，你們到時候後端做完一接就完事了，應該不難吧？」
就這樣，大家你一言我一語，沒有人願意在清單上被往後排，大家提出的需求都是對他們自己來說最重要的功能。
眼看著事情疆持不下，營運副總站出來主持公道了：
「那個… 我了解這些事很重要，各位對公司來說都是不可或缺的角色，但 API 部門忙不過來也是事實。我想，你們一定會討論出一個適當的解決方法的，畢竟，事有輕重緩急，對吧！但我要強調，大家還是要注意企業文化與橫向溝通，彼此尊重並共創雙贏…（以下省略三千字）那個 Mike 呀，你就多開 15 個 Java 職缺吧。大家加油！」
這是發生在你我身邊的故事…
其實，要了解一個人真正的想法，對方說了什麼根本不重要，他做了什麼才重要。上面的故事中，副總講了這麼多，但真正用行動傳達出來的訊息只有兩個：
加人的議題我們會另外聊，這裡我們先專心討論「我全都要」的議題吧。
Lean Startup 我想大家或多或少都有聽過。這個工作方法起源於上個世紀末，汽車製造廠 Toyota 的管理方法。在 Toyota 的裝配廠，有很多當時很特別的制度，筆者認為綜合起來可以歸納為：
於是你會看到明明是照明系統出了問題，車門也要停止工作；明明是儀表板產線出錯了，內裝也暫停生產。為什麼？因為很簡單：「我們是賣車的，不是賣零件的，整台車都正常，才叫一台車。」
Toyota 的做法，其實背後的原理也很單純，就是透過減少半成品，減少庫存量，來減少浪費，進而提高企業每一分投資的價值。假設今天的生產目標是 3,000 台汽車，當車門的生產出了問題，你生產再多組車燈也是白費，因為沒有人會買一台沒有車門的汽車。
一開始的故事背景是發生在軟體業。那軟體業也適用這套理論嗎？筆者認為很大程度也是適用的。
在一開始的例子中，Mike 的部門負責的工作，看起來經常要嘛是別人的上游，不然就是下游，而且這間公司裡，每個部門不只負責的工作不同，連商業目標也不一樣。因此，你可以看到，就算 API 忙不過來，行銷也要先在澳大利亞專案中先發包廣當，不管廣告引進來的人能不能享受到廣告內號稱的功能。就算 API 忙不過來，產品也要等 API 做出真正的核心演算法，才要做他們眼中的「效果」，他寧可在那等，也不處理 prototype 來先期驗證。會計跟前端更是奇怪，就算 API 忙不過來，他們也要先把前端做起來放著，即便一個沒 API 可打的會計總帳網頁一點用都沒有。
這一切決策，都在反映一件事：這間公司的每個部門都只關心一件事：「Local 最大化」。
Local 最大化與 Global 最大化，有時候會高度相關，但大部份時候不會。為什麼？很簡單，因為 Local 最大化才能最大化每個部門各自的表現分數（例如 KPI）。當各部們專心最大化自己的產出時，「等待」就產生了。然而，等待在傳統觀念上又很容易看起來像是偷懶，於是大家這麼聰明，一定會把自己的管轄範圍產能拉到最高，於是「半成品」就出現了。
回到上個世紀末的，Toyota 為什麼他們這麼在意半成品的控管，因為他們知道只有「一台車」能帶來價值，而如果各部門生產出來的零件沒有辦法剛好組成一台車，那多出來的每一個零件，就是生產成本的浪費。
然而，這也不是部門主管的錯，注重部門產出量的最大化，本來就是組織交付給他們的最重要工作。如果因為考量整體最大化而降低了部門 KPI，誰又要負責？事實上，當你公司依照職能分部門，又給他們分散的目標時，產出並躺在部門與部門之間，還無法在市場上創造收入（價值）的半成品，就成了早晚得面對的課題。
在軟體開發中，要減少創造不了價值的半成品，方法有蠻多的。有人偏好「全能人才」，全能人才前端能做、後端也能做，網路略懂，SQL 也不會亂下，這樣的人在產品有任何需要時都能處理，自然能減少半成品。但，全能人才何其稀有，因此另一個解方就是「全職能團隊」，在全職能團隊中，每個人不是全能，但一個團隊就能交付一個產品。只要團隊力量不要發散，就可以讓每個經手的工作都能快速脫手。有研究過商務原理的讀者就知道，這就跟餐廳提高『周轉率』的效果是一樣的。
你說，那我不要全職能團隊，我維持部門分組，但叫他們同時做同一個產品不也一樣嗎？可以，也就是透過「限縮目標」，來提高週轉率。咦，這不就 Kanban 方法裡面的『WIP Limit 嗎？』對啊，本質上就是呀。這個解法是上述三個解法裡面，可以最快開始，付出代價也最小的。唯一的阻礙，就看上頭的『營運副總』有沒有相通這件事了。
最後，各位讀者看到這邊，你覺得這樣下去還要加人嗎？私以為，加是當然可以加的。當你開一間印刷工廠，所有機器之間的運作協調都已經提高，所有工廠內的內耗與機器間的庫存都降到最低，這時再來加買機器，才能把買機器的成本效益發揮到最高。
人的問題也是一樣，先把等待跟內耗減少，你加人的效益才看得出來，不是嗎？
謎之聲：「沒有車門的汽車，裝一百車盞燈也沒用。」
iThome鐵人賽
看影片追技術